These different kinds of traffic processing are implemented in an IP domain by means of devices known as “service functions”, referred to below as “SF functions”. By way of example, among the SF functions commonly in use there are to be found:                quality of service functions, such as marking and classifying traffic, or conditioning or scheduling traffic;        security functions, such as encrypting traffic, installing and activating filters defined by access control lists maintained by certain routers of the IP network, and IPv4 or IPv6 firewalls;        network address translation (NAT) functions or NAT64 functions (i.e. mechanisms enabling IPv6 clients to communicate with IPv4 servers;        probe functions, such as deep packet inspection (DPI) functions, e.g. for parental control purposes;        functions for personalizing or optimizing Internet connections, such as “TCP optimizer”;        video content optimization functions (e.g. a cache function); or indeed        functions for inserting information in hypertext transfer protocol (HTTP) headers, e.g. “X-forwarded-for” (X-FF) or “forwarded”.        
SF functions may be hosted by all kinds of equipment, e.g. a router, a server, or a switch. Furthermore, a single piece of equipment may host one or more SF functions.
In the context of the present invention, it is said that a node of an IP domain is “associated” with an SF function when the SF function is hosted by the node or is accessible via the node; in addition, a node associated with at least one SF function is referred to as an “SF node”.
Installing a value-added service based on a policy of differentiated traffic handling (such as a traffic handling and routing policy, or quality of service, or indeed security such as encrypting transmitted data) generally requires a plurality of SF functions in combination (which may be hosted on one or more nodes of the network), possibly in an order that is characteristic of the traffic flow direction (e.g. from the Internet to a terminal or from a terminal to the Internet), in order to form functional chains. An ordered sequence of SF functions is referred to below as a service function chain (SFC). In other words, the chaining of service functions specifies a list of SF functions to be used for processing a data stream characteristic of said service, and the order in which the functions are to be used in sequence for processing the stream. It should be observed that the service function chains associated with each traffic direction (incoming traffic v. outgoing traffic) may be identical or different.
For example, transmission control protocol (TCP) traffic from clients having only an IPv6 protocol stack can involve chaining a TCP optimization function, an IPv6 firewall function, and a NAT64 function in order to enable such clients to access IPv4 content available on the Internet; and the processing of the TCP traffic for such IPv6 clients can involve changing an IPv4 firewall function and a NAT64 in order to enable those clients to receive said IPv4 content available on the Internet. Another example is that of a virtual private network (VPN) service on IP, which makes use of handling and routing functions combined with quality of service functions and security functions distributed in different elements making up the network supporting the VPN, or in elements that are connected to the support network, such as a firewall.
Explicit indication means (e.g. marking conveyed by each packet belonging to a given stream) can then be used to inform the piece of equipment hosting the individual SF functions about the chain of which they form a part in order to process the stream(s) associated with that chain. Each piece of equipment hosting at least one individual SF function making up an SFC then refers to this explicit indication in order to decide how each packet belonging to said stream is to be processed.
If no explicit indication means are used, then so-called “classification” functions may be activated to determine whether or not a given SF function is to be invoked. A node associated with at least one classification function is referred to as a “classifier”; a classifier is thus a device of the IP domain that acts as a function of the SFCs available within the IP domain to classify the different kinds of traffic and to invoke SF functions in the appropriate order.
Service function chaining techniques are recent. The state of the art shows that the first developments of this service function chaining technique rely on monolithic single-manufacturer approaches.
Thus, the article by M. Boucadair, C. Jacquenet, R. Parker, D. Lopez, J. Guichard, and C. Pignataro entitled “Differentiated service function chaining framework” (available at the address tools.ietf.org/html/draft-boucadair-sfc-framework-00), describes a procedure for creating a chain of service functions. Furthermore, it describes a generic service function chaining architecture together with the functional entities that are needed for installing such an architecture. Specifically, that article gives the responsibility of constructing SFCs to entities referred to as policy decision points (PDPs).
It should be recalled in this respect that the resource allocation protocol (RAP) working group of the Internet engineering task force (IETF) has defined, in a document RFC 2753, a functional architecture that is specific to managing networks implementing one or more different traffic handling policies. In particular, that architecture defines devices referred to as PDPs that are responsible for taking decisions about the structuring of a service relying on a set of SF functions, and for notifying these decisions to the network nodes that are involved in deploying and operating said service. In particular, the PDP is responsible for taking decisions representing various different traffic handling policies that need to be executed by one or more nodes of the network, and that lead to ad hoc functions being configured in the network nodes that are concerned. By way of example, PDP devices may be hosted in a server, a gateway, or a router.
In the context of the present invention, the term “PDP node” is used to designate a node hosting or giving access to a PDP device. It should be observed that a node of an IP network may optionally be associated both with a PDP device and with one or more SF functions.
According to the above-mentioned article by Boucadair et al., the PDP communicates with the SF nodes or with nodes hosting a stream classification function (or a combination of both), giving instructions about installing different traffic handling policies, which are characterized by the various SFCs used for processing all of the traffic streams handled in the network depending on their natures. The article states in particular that the PDP must have knowledge of the list of service functions that are active in the network together with their locations.
Once these SFCs have been structured by the PDP, the nodes of the network are informed about them. By way of example, this may be done in the form of a map describing SF functions that are to be executed in a certain order for a certain type of data traffic associated with said map. Receiving this map makes it possible in particular for a node of the network to determine its position in the SFC and, in compliance with the instructions of the SFC, make use of the SF functions that are associated therewith, and then to determine which is the following SF node to which the traffic is to be transferred.
In the context of installing and using complex network services (i.e. relying on different individual service functions being used in order), the person skilled in the art will readily understand that a procedure for diagnosing SF functions and SFCs is an addition that is both natural and necessary for the technique of chaining SF functions. For example, a diagnostic procedure is required in particular in value-added service environments such as:                telemedicine services for which the ability to guarantee the handling of traffic characteristic of modifying biometric data (e.g. in real time) relies on intelligent chaining of traffic engineering functions (calculating and setting up routes having characteristics in terms of performance and robustness that are compatible with the nature of said traffic), of quality of service (e.g. traffic prioritizing functions), and of security (e.g. encrypting data before transmitting it over the network); the very nature of this type of service requires diagnostic procedures that are appropriate both in terms of automating the diagnostic process and in terms of the performance of such processes; or        virtual private network (VPN) services, that need to be engineered and operated in compliance with the contract negotiated with the client of said service; a VPN service relies on a combination of service functions that can often be complex (e.g. functions of handling and routing traffic within the VPN, classification functions, marking and conditioning the traffic handled within the VPN, security functions such as activating access filters and firewalls for protecting access to sites connected via the VPN), and that require diagnostic tools that are reliable and of high performance; the process of diagnosing service functions used in a VPN contributes to guaranteeing to the client that the service provided is in compliance with the negotiations between the client and the network operator.        
In order to determine whether an IP machine is reachable in the IP routing sense, mechanisms are known such as those provided by the Internet control message protocol (ICMP). Nevertheless, the fact that an SF function is accessible at IP level does not mean that it is operational. Furthermore, for any given SFC, ICMP messages are conveyed along IP routes that are set up in the network in conventional manner, and not along routes that are followed by traffic associated with an SFC, which may be different from conventional IP routes.
By way of example, a DS-Lite function known as address family transition router (AFTR), as defined in IETF document RFC 6333 which acts like a router facilitating the transition from IPv4 Internet to IPv6 Internet, and embeds in particular NAT type and encapsulation type SF functions, might not be operational even though it responds to ICMP messages: the AFTR function is operational if, and only if, the IPv4-in-IPv6 encapsulation/decapsulation and NAT components are both operational.
The ICMP protocol suffers from several drawbacks. In particular:                it does not detect the non-availability, if any, of an SF function that is indeed reachable;        it does not provide a diagnosis of an SF function, an SFC, or a subset of SF functions within an SFC (where such a subset is referred to in the context of the present invention as an “SF function sequence”;        it does not provide a diagnosis of traffic classification rules (where the term “classification rules” is used to designate rules used to handle traffic in the network as a function of the SFC with which given traffic is associated);        it does not make it possible to calculate the delay or the jitter associated with handling the traffic associated with an SFC within the network;        it does not make it possible to verify that the list of SF functions does indeed correspond to what was configured by the administrative entity in charge of operating the network; and        it does not make it possible to select an operational SF function from a plurality of SF functions of the same kind, such that the SFC can be built up from a set of SF functions that are considered to be operational as a result of the diagnostic procedure.        